I would argue that providing a constructor like this would be more conventional for the web:

Since often there are multiple canvas elements on the page, users should be able to control which is used.

One of the goal was to keep the python code portable between auto backends. So passing a string to __init__() would work even on backends where this kwarg isn't used like glfw and the user doesn't need to use any pyodide specific code in python. (Once we have a wgpu-py version for browser, most examples should just work without changes to shadertoy, pygfx or fastplotlib etc).

I also losely followed the idea of https://pyodide.org/en/stable/usage/sdl.html#setting-canvas where they provide a specific API to accessing the canvas, although I not using it.

Maybe I can write a little multi canvas example to see if my approach works.

I have zero webdev experience, so my design decisions are directed to the python devs wanting to write their python code (like myself).

I have zero webdev experience, so my design decisions are directed to the python devs wanting to write their python code (like myself).

I hear you, but just because you can use python the language, doesn't mean you can "ignore" the environment it's running in! I don't mind what kind of API you choose (I value portability as well) as long as the user can control which <canvas> is used.

I imagine python devs turning to browsers will often do so because they want to use the browser's capabilities to build the UI they have in mind. It's easy to envision applications with multiple canvases embedded in a richer UI.

it shouldn't be impossible to support both.
canvas_el: [str|HTMLCanvasElement] = "canvas"

would work even on backends where this kwarg isn't used like glfw

apparently kwargs don't get ignored when a different auto backend is selected because the base class calls super.__init__(*args, *kwargs). We could use the title arg as I am not sure if that has a use in the browser, but that seems janky.

For resizing, have a look at window.ResizeObserve: I use this code in another project to get the physical size (it's PScript, so you need to convert to Python/JS depending on where it runs):

        # Inside the  ResizeObserve callback ... 
        entry = entries.find(lambda entry: entry.target is self.node)
        if entry.devicePixelContentBoxSize:
            # Best if we have the physical pixels ...
            psize = [
                entry.devicePixelContentBoxSize[0].inlineSize,
                entry.devicePixelContentBoxSize[0].blockSize,
            ]
        else:
            # ... but not all browsers support that (see issue #423) ...
            if entry.contentBoxSize:
                lsize = [
                    entry.contentBoxSize[0].inlineSize,
                    entry.contentBoxSize[0].blockSize,
                ]
            else:  # even more backward compat
                lsize = [entry.contentRect.width, entry.contentRect.height]
            ratio = get_pixel_ratio()
            psize = Math.floor(lsize[0] * ratio), Math.floor(lsize[1] * ratio)

In general the standard reference material for browser APIs is on MDN, in this case see this page for example usage: https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver

finally found a bit of time to implement this - also tried to make the demo page react and it seems to work. Altough I am not sure if this matches real webframeworks

I'm pretty sure we can hook things up in a clean way, but I will need to sit down and play a bit to get it right.

feel free to commit into this branch or similar if you have the capacity. I am very much out of my depth with the web stuff and also don't have too much time currently (settling into new job and new university) to sit down for some long evenings and figure it out.

I think asyncio can be used in Pyodide, right?

edit: should have read more before reacting. So is pyodide.webloop a sort of more native loop implementation?

yes, they overwrite a couple of functions.
But I should try to use the async loop class and see if this whole class can be avoided.

edit: you can't find much on it in the docs so I looked at the source and went from there. Perhaps other prominent pyodide packages provide some specific insight. I pretty much learned all my async and js knowledge from attempting this. Surprised myself it sorta works. But this obviously means I might be doing something wrong.

Can I ask why a loop is needed at all? Why not just implement call_later with setTimeout and leave everything else to the browser's native loop?

Loop is made to fit into the existing rendercanvas implementation, although it can likely be simpler with more changes. Very much out of my depth here.

The docstrings here says as much, although I am not sure if that's happening all the way down. https://github.com/pyodide/pyodide/blob/bcd0235bff5351d1dc383e4f3e34b9917fdf3281/src/py/pyodide/webloop.py#L280L294

Yeah it is: https://github.com/pyodide/pyodide/blob/bcd0235bff5351d1dc383e4f3e34b9917fdf3281/src/py/pyodide/webloop.py#L330

The point is that in the browser there already is an event loop driving the page, and you can not get a reference to it. So I am just wondering what the point of having an event loop abstraction is inside a browser, apart from compatibility.

okay, so I tried with the asyncio loop and it works just fine. Also not calling loop.run() at the end of an example still works.

so should I drop my loop class and just import the asyncio loop instead?

so should I drop my loop class and just import the asyncio loop instead?

Yes, let's just do that. It's the simplest to do, and makes sure all works together if the user uses asyncio for other stuff.

one more consideration that might be complex to implement: use the browsers requestAnimationFrame with a callback to run the loop? I spotted something like this here: https://github.com/pyglet/pyglet/blob/5d1fe49db83bd2c060d97226e1334f06a706b1fc/pyglet/app/async_app.py#L64

Using requestAnimationFrame is the standard approach for rendering, since it automatically pauses when the tab becomes hidden for example.

yeah, with some of the wgpu examples I am having issues where the animation stops randomly or when you change tab etc... it just suspends and doesn't recover. So we might need a webloop or whole sheduler... the rendercanvas bitmap examples seems to survive tab switching